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Abstract 


Numerical programs spend more time executing in loops than in the remaining code 
segments. Consequently, restructuring loops to utilize the underlying architecture 
should lead to overall reduction in the program execution time. For vector processors, 
these loop optimizations generally include all transformations that result in genera- 
tion of better vector code. In this thesis, we shall discuss issues related to the loop 
optimization tecliniques like loop interchange, node splitting, and conversion 
of conditionals for execution on vector processors. Loop interchange involves inter- 
changing loop positions in a tightly nested loop body, to alter the execution sequence 
of statement instances in the loop body. Such a transformation moves recurrences 
involving a majority of statements outwards, thereby allowing the inner loops to be 
vectorized. Node Splitting entails eliminating dependence cycles having an antide- 
pendence edge as a component. This is done by splitting the statement causing the 
antidependence, with the introduction of a new compiler temporary variable. Finally, 
conversion of conditionals to vector form involves transformation of IF constructs that 
do not branch out of the enclosing loop body to equivalent vector WIIFRF constructs 
of Fortran 90. 
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Chapter 1 
Prologue 


Computers have been applied to problems from various fields. As a result, millions of 
lines of serial code have accumulated over the years into what are popularly known 
as dusty decks. Technology too, has progressed to meet this demand for computation 
power in the form of new architectural paradigms. One such advancement is the 
vector computer, which exploits concurrency in data to speed up computations. Just 
as there are “optimizing” compilers for serial computers, which generate code that 
can make “optimal” usage of the underlying serial architecture, compilers that do the 
same for vector processors are also needed. Extending the concept a little further, it 
is possible to develop a compiler that takes a sequential program, performs various 
optimizations on it, and produces code that effectively exploits the underlying vector 
architecture. This approach serves two purposes: 

1. Absolves the user from the burden of knowing the intricacies of underlying 
architecture (for writing programs that execute faster on that machine), 

2. Already written sequential programs can be executed without being rewritten 
for the vector architecture. 

The Fortran 90 (F90) [11] vectorizing compiler being built at the Indian Institute 
of Technology, Kanpur, is one such effort directed towards meeting the above stated 
purposes. 
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1.1 The F90 project : A perspective 

The F90 vectorizing compiler being built at IIT/K envisages producing an ‘optimized’ 
and ‘vectorized’ Fortran 90 program from an input program from the Fortran 77- 
Fortran 90 class of languages. Figure 1.1 depicts the overall structure of the F90 
compiler [20, 21]. The functions of each of these phases, very briefly are as follows: 

• The preprocessor handles compiler directives such as file inclusion and presents 
to the lexical analyzer an “expanded” version of the input program. 

• The lexical analyzer accepts the input stream of characters from the prepro- 
cessor, identifies the lexemes and feeds to the parser. 

• The parser uses the lexemes received from the lexical analyzer and recognizes 
the syntax structures formed by them, simultaneously constructing the syntax 
tree representation of the input program. 

• The optimizer performs scalar code improvement transformations such as con- 
stant propagation and folding on the input syntax tree after analyzing the pro- 
gram for aliases and reaching definitions. 

• The vectorizer performs vector optimizations on the program to uncover latent 
parallelism in the program. These optimizations include detecting auxiliary 
induction variables in loops, loop restructuring and converting array references 
and conditionals to equivalent vector forms, if possible. 

• The backend, by a process called unparsing, generates the scalar and vector 
optimized Fortran 90 equivalent of the input program. This is in aid of the user, 
who can use it to analyze the optimizations performed on the input program. 
We also hope that the user will use this feedback to issue the compiler directives 
to aid optimization. 

• The translator phase converts the syntax tree output by the vectorizer to a 
low level internal representation {operator tree) in which each non-leaf node 
represents an operator and leaf node, an operand. 





Figure 1.1: The F90 Compiler 
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• The code generator generates the assembly language equivalent of the oper- 
ator tree input it receives from the translator. 

1.2 Vector Features of Fortran 90 

Fortran 90 [11] provides vector constructs for array references and conditional assign- 
ments. These advanced features can effectively utilize the underlying vector hardware. 
Here, we give a brief description of these features; 

Array assignment. If A and B are two arrays of the same dimension N, then 
A = B 


assigns B(i) to A(i) for each 1 < i < N. 

Sections of arrays can also be referenced using the triplet notation. If M < N, 
and A and B are two N x N arrays, then 

A( 1:M:1, I ) = B( J, 1:M:1 ) 


assigns the elements of the row of B to the column of A. 

In this triplet notation, the first two components specify the range of iteration 
and the third component specifies the “stride” for the index vector in that 
subscript position. 

Conditional Assignments. Fortran 90 provides a facility for making conditional 
assignments through WHERE statements or constructs. We will only present 
an instance of its usage here. The syntax is presented later (Chapter 4) when 
we talk about vectorizing conditionals. 



If A and B are arrays of same dimension N, then 


WHERE ( A .NE. 0 ) B = B / A 
ELSEWHERE B = 1 


makes a test for A(i) 7^ to 0 and makes the assignment to B(i), 1 < i < N, accordingly. 

Here A is called he mask array. 

1.3 Work done here 

The work outlined in this report concerns the vectorizer phase of the F90 compiler. 

In particular, we will be concentrating on the following code restructuring techniques: 

Loop Interchange. This is one of the techniques under the Reordering transforma- 
tions category of restructuring techniques, which includes all transformations 
that affect the order in which the code is executed. Loop interchange is a 
powerful aid for vectorization. It alters the order in which the loops inside 
a loop nest are executed by interchanging positions of the loops. The data 
dependences within the loop nest have to be analyzed to safely perform this op- 
eration. Later, we formalize the notion of interchange preventing dependences, 
and provide algorithms for determining when a loop interchange is valid and 
profitable. 

Breaking cyclic dependences. Presence of some “pseudo” dependences such as 
antidependences as components of dependence cycles inhibits vectorization. 
Such dependence cycles can be broken by introducing new compiler variables 
for the antidependence causing variables. This teclmique, called node splitting 
is de.scribed in detail Chapter 4. 

Vectorizing conditionals. The theory of restructuring compilers is oriented to- 
wards data dependences. The fact that most vector computers provide some 
facility for simultaneous conditional execution of statements adds a whole new 
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dimension to the proceedings. This is so, because IF constructs introduce what 
are known as control dependences which must be taken into account while vec- 
torizing. In Chapter 4, we do an in-depth analysis of the various issues involved 
in vectorizing IFs. 

1.4 Organization of the report. 

The rest of the report is organized as follows 

• Chapter 2 overviews the vectorizer and the intermediate representation 
used, the Pivgrain Dependence Gmph. 

• Chapter 3 deals with the concepts of data dependence and analysis. 

• Chapter 4 details various restructuring techniques applicable to vector- 
ization 

• Chapter 5 summarizes the work done, suggests extensions to the project 
and outlines the testing carried out. 

With this pmlogue we proceed to take a closer look at the various issues. 




Chapter 2 
Introduction 


2.1 Overview of the Vectorizer 

This section presents an overview of the different phases of the vectorizer which 
is depicted in Figure 2.1. The functions of the various stages of the vectorizer 
are very briefly outlined here. Most of these phases are explained in detail in 
this and the following chapters. 

Control Flow Graph generation: The scalar optimizer, the stage preceding 
the vectorizer, produces syntax tree, which is input to the vectorizer. The 
structure of this syntax tree is similar to that of the syntax tree produced by 
the parser. This stage of the vectorizer concerns itself with the conversion 
of this syntax tree into a control flow graph. 

Control Dependence Subgraph generation: This is the first stage in the 
construction of the Program Dependence Graph ( PDG ) [10]. The control 
dependence subgraph of the PDG is built from the control flow graph using 
the method explained in Section 2.2. 

Data Dependence Subgraph generation: Scalar dependence edges are added 
to the control dependence subgraph using classical data flow analysis tech- 
niques [2]. The output of this phase is the complete PDG. 

Loop Normalization: This phase takes the PDG, and transforms loops so 
that the loop induction variables iterate from 1 to some upper bound by 
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increments of 1. This is accomplished sometimes by the introduction of 
now iiuluction variables. All roforcncos to the old iiuluotion variables within 
the loops are replaced by expressions in the new induction variables. 

Auxiliary induction variable elimination: Sometimes, the subscript expres- 
sions of the array references within loops will be in terms of some ‘auxiliary’ 
variables that go in tandem with the actual loop induction variable. These 
auxiliary induction variables can be eliminated by replacing them with 
references to the actual loop induction variables. 

With the completion of this phase, we will have all the loop induction 
variables incrementing from 1 to some uj>per bound in st<'])s of 1, and 
all array subscripts converted to linear functions of the loop induction 
variables. Such loops are said to be standardized. 

Data dependence analysis: Scalar data dependence analysis treats any ref- 
erence to an array element to be a reference to the whole array. Such 
conservative estimation of data dependences will not suffice for effective 
exploitation of parallelism inherent in programs. More accurate data de- 
pendence information can be got by analyzing the array subscripts. This 
phase adds the array data dependence edges to the PDG. 

Loop Interchange: In many cases, it is possible to enhance vectorization by 
interchanging the nesting order of loops. Called loop interchange, thi.s 
transformation is semantically feasible and profitable under certain condi- 
tions. This phase concerns itself with identifying and performing feasible 
and profitable loop interchanges. 

Node Splitting: Presence of some pseudo dependences in a dependence cycle 
hampers vectorization. With some ingenuity, such dependence cycles can 
be broken. Node Splitting is one such technique, which in the literal sense 
..means splitting a node (statement) into two nodes (statements), in the 
process introducing a new variable to eliminate the pseudo dependence. 
This phase entails breaking such dependence cycles. 




Figure 2.1: The F90 Vectorizer 
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Vector code generation: This phase concerns itself with identifying vector- 
izable statements and generating the vector code for them. Wherever 
possible, vector constructs of Fortran 90 replace array references and IF 
constructs in the vectorized version of the input program. 

Control flow graph recovery: This phase reconstructs the control flow graph 
from the PDG. The control flow graph generated, if different from the one 
that the vectorizer received as input, will represent the vectorized version 
of the input program. 

Syntax tree recovery: This phase ensures inter-operability of the vectorizer 
with the other phases of the F90 compiler; it generates the syntax tree 
acceptable by the next phase (Translator), the structure of which is the 
same as the syntax tree generated by the parser. The Translator is non- 
existent as of now. Hence the output of this phase goes to the optional 
unparser phase of the compiler which in effect generates the Fortraii 90 
equivalent of the syntax tree. 

2.2 The Intermediate Representation 

The F90 vectorizer uses the Pivgram Dependence Graph (PDG) [10] as the inter- 
mediate representation. The PDG provides a unified framework in which various 
optimizations and program restructuring techniques may be applied. Defore the 
PDG was proposed, some optimizing compilers used data dependence graphs 
[19] for an explicit representation of the definition-use relationships implicitly 
present in a source program, and the control flow graph [2] to represent the 
control flow relationships in a program. The control flow graph however, has 
the undesirable property of a fixed sequencing of operations that need not hold. 
The PDG explicitly represents both the essential data dependences, as present 
in the data dependence graph, and the essential control relationships, without 
the unnecessary sequencing present in the control flow graph. These dependence 
relationships determine the necessary sequencing between operations, exposing 
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potential parallelism. 

2.2.1 The Program Dependence Graph : Concepts 

The PDG represents a program ai a directed graph in which 

• the nodes are statements and predicate expressions, and 

• the edges incident to a node represent 

— the data values on which the node’s operations depend, and 

- the control conditions on which the execution of the operations de- 
pend. 

The set of all dependences for a program may be viewed as imposing a partial 
ordering on the statements and predicates in the program that must be followed 
to preserve the semantics of the original program. 

Dependences result from two separate effects. First, a dependence exists ber 
tween two statements when they have references to some common memory 
location, and at least one of them writes that location. Such dependences are 
the data dependences. We will talk about data dependence in detail in Chap- 
ter 3. Second, a dependence exists between a statement and a predicate whose 
value immediately controls the execution of the statement. For example, in the 
sequence. 


if (P) then 

52: C = A * B 

endif 


$2 depends on predicate P since the value of P determines whether S 2 is exe- 
cuted. Dependences of this type are control dependences. 
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The PDG unifies these dependences in the sense that it is conaposed of a control 
dependence subgraph and a data dependence subgrapli of the program being 
represented. 

We will now briefly look at the construction of the PDG beginning with some 
essential formal definitions [10]. 

Control flow graph. A control flow graph is a directed graph G augmented 
with a unique entry node START and a unique exit node STOP such that 
each node in the graph has at most two successors. Tire nodes with two 
successors are assumed to be having attributes “T” (true) and “F” (false) 
associated with the outgoing edges, and for any node N in G, there exists 
a path from START to N and a path from N to STOP. 

Post-dominators. A node V is post-dominated by a node W in G if every 
directed path from V to STOP (not including V) contains W. Note that, 
by definition, a node never post-dominates itself. 

Control Dependence. Let G be a control flow graph. Let X and Y be nodes 
in G. Y is control dependent on X iff 

1. there exists a directed path P from X to Y with any Z in P (excluding 
X and Y) post-dominated by Y, and 

2. X is not post-dominated by Y. 

2.2.2 Control Dependence Subgraph 

The algorithm below gives the procedure for construction of the control depen- 
dence subgraph of the PDG. The reader is, how'ever, encouraged to look up [10] 
for a detailed discussion on the construction and applications of the PDG. 
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Step 1: Augment the control flow graph with a special predicate node ENTRY 
that has one edge labeled “T” going to STAR!' and another edge labeh'tl 
“F” going to STOP. ENTRY corresponds to whatever external condition 
causes the program to begin execution. 

Step 2: Construct a post-dominator tree for the augmented control flow graph. 
Computing the post-dominators in the control flow graph is equivalent to 
coin])uting dominators [2] in the reverse control flow graph. The algorithm 
in [13] can be used for this purpose. 

Step 3: Let S consist of all edges (A, B) in the control flow graph such that B 
is not an ancestor of A in the post-dominator tree (i.e., B does not post- 
doininate A). Proceed by examining eacli edge (A, B) in S. If L denotes 
the least common ancestor of A and B in the post-dominator tree, either 
L is A or L is the parent of A in the post dominator tree (for a proof of 
this, see [10]). 

Case L = parent of A. Make all nodes in the post-dominator tree on 
the path from L to B, including B but not L, control dependent on A. 
Case L = A. Make all nodes in the post-dominator tree on the path from 
A to B, including A to B, control dependent on A. 

Step 4: This step concerns the addition of region nodes (predicate nodes) to 
summarize the set of control conditions for a node and group all nodes 
with the same set of control conditions together. First, we consider the set 
CD of control dependence predecessors of each nonregion node that has 
other than a single unlabclcd control dependence predecessor. A region 
node R is created for CD and each node in the graph whose set of control 
dependence predecessors is CD is made to have only the single control 
dependence predecessor R. Finally, R is given CD as its set of control 
dependence predecessors. 

The entire algorithm for the construction of the control dependence subgraph 
takes time O(A^), where N is the number of nodes in the control flow graph. 
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2.2.3 Data Dependence Subgraph 

Classical data flow analysis techniques [2] and the array dependence analysis 
presented in Chapter 3 are used for the construction of the data dependence 
subgraph of the PDG. Data flow analysis computes the set of reaching definitions 
[2] for each statement. The results of the data flow computation are then 
explicitly represented in the PDG by adding edges from the definition nodes to 
the corresponding use nodes. References to any element of an array are treated 
as references to the whole array. Depending on the order of the definition 
and use, edges are marked as flow, anti or output [19, 2] dependence edges. 
Data dependence analysis [7] is then used to update the data flow subgraph. 
Data dependence analysis considers subscripts of the array references for more 
accurate computation of the flow of data. We will go into the details of data 
dependence analysis in Chapter 3. 

2.2.4 An Example 

We consider a small sample program and illustrate the structure of the PDG 
constructed for it. Figures 2.2(a) and 2.2(b) show the control flow graph and 
the complete PDG for the program. The solid lines represent control edges 
while the dotted lines represent data dependences. Control dependences are 
labelled with “T” and “F” for TRUE and FALSE conditions of control flow, 
respectively. Unlabelled control edges represent unconditional execution of the 
successor statement. Data dependences are labelled with “flow”, “anti” and 
“out” which represent the true, anti and output dependences, respectively. 





Figure 2.2: The Control flow graph and PDG for the example program 


Si: DO I = 1, 100, 1 
52: IF (X (I) .GT. 0) then 

53 : Y(I) = 1 

ELSE 

54 : Y(I) = X(I-l) 

END IF 


ENDDO 









Chapter 3 

Data Dependence Analysis 


As we mentioned in Chapter 2, dependences in programs occur in two types: 
control and data dependences. Control dependences occur as a consequence of 
the flow of control in a program. For instance, the statements in the if-then 
block of a program are control dependent upon the if test. The other type of 
dependence, data dependence occurs as a consequence of the flow of data in 
a program. Data dependences have been given thorough treatments in [7, 25]. 
In what follows, we present the bare minimum of the concept, terminology and 
analysis of data dependences. This should be sufficient to help the reader ap- 
preciate the importance of this topic, which stems from the fact that complete 
vectorization of statements involved in cyclic dependences is not possible. Ef- 
fective tests have been developed to identify the presence or absence of such 
dependence cycles, and the later phases utilize this information to generate 
vector code. 

3.1 Definitions, Concepts and Terminology 

Statement T depends on statement S (S A T) if there exist an instance S' of S, 
an instance T' of T, and a memory location M, such that 

1. Both S' and T' reference M, and at least one of the references is a write 

2. In the serial execution of the program, S' is executed before T', and 
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S : M = ... 

T : ... = M 

Figure 3.1: True dependence between two statements 

3. In the same execution, M is not written between the time S' finishes and 
the time T' starts. 

Kuck and others [19] classify the dependences beised upon the two types of 
references to M [5]. 

Flow dependence or True Dependence. S' writes and then T' reads it. 
Flow dependence is denoted by S ^ T and is illustrated by Figure 3.1. 

Antidependence. S' reads M and then T' writes it. Antidependence is de- 
noted by S 5 T and is illustrated by Figure 3.2. 

Output Dependence. S' writes M and then T' writes it. Output dependence 
is denoted by S 6° T and is illustrated by Figure 3.3. 

Thus we can say that A = ^ U 5 U [5], which means T depends on S if any of 
the above three dependences hold between S and T. In all the three cases, S is 
called the source and T the sink of the dependence. 

Formally, given a loop nest as in Figure 3.4, where m represents the number of 
subscripts of array X, a dependence from S to T exists iff the following holds: 

fk[i\, • • ■ , *n) = ■ • , jn), Vfc, l<k < m 

Here are instances of /,, \ < q < n. 

S : ... = M 
T : M = ... 




Figure 3.2: Antidependence between two statements 







Figure 3.3: Output dependence between two statements 


DO h = l,Ni 

Do h = i,yv 2 


D0 7„ = l,iV„ 

ENDDO 


ENDDO 

ENDDO 


Figure 3.4: A general loop nest for linear dependence problem 
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Distance Vectors. For each data dependence involving statements S(ii , . . . , i„) 
and whore n loops siirroitiid S and 'I', wo dofiiio tlu' 7 '^ 

distance or Dr{6) to be = jr — iri (1 ^ ^ ”)• The n-tuple 

D = {Di,D 2 ,- ■ ■ ,Dn) is called dependence distance vector [23]. 

Distance represents the number of iterations that must elapse between the 
execution of the source and the sink of the dependence, and is important 
for some advanced compiler optimizations like shrinking [23]. Distance 
also implicitly makes known the direction of the dependence arrow. 

Direction Vectors. In many caaes it is not possible to compute accurately 
the distance vector of a dependence. A simpler but less exact description 
of the data dependence direction is the sign of the dependence [25]. 

Thus, for each data dependence involving statements S(ii,...,tn) and 
T(ii, . - • ,jn) where n loops surround S and T, we define the direction 
dr or dr{S) to be dr = sign{jr — *r)>(l < r < 7i). Here, 

• sign(x) = “<” if X < 0 

• sign(x) = “=” if X = 0 

• sign(x) = “>” if X > 0. 

The n-tuple d = (di,d 2 ,-- -i^n) is called dependence direction vector [7]. 
The direction of dependence for a loop is 

forward, if sign(yr ~ir) is “<”, i.e., a dependence exists from an iteration 
to a subsequent iteration 

equal, if sign(yV — *r) is “=” i-e., a dependence exists in the same iteration 
backward, if sign(jr — *r) is “>” i-e., a dependence exists from one iter- 
ation to an earlier iteration 

An asterisk {“*”) is used when the direction is unknown or all of “>”, 
apply. 

Loop Carried and Loop Independent dependences. Dependences can be 
further classified as being “carried” by a particular loop or being indepen- 
dent of loop iterations. 
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Referring to Figure 3.4, we say statement T has a loop carried dependence 
on S (denoted S <5 T) if there exists some iV and jr such that 1 < ir < jr ^ 
Nr, (1 < r < n) and each of 

f k{^l, • • • , Ir , • • • , ^n) — 9k{,Jl , • • • , jr, • • • , jn )> 1 ^ ^ ^ 

holds. Note that self dependence is merely a special ceise of loop carried 
dependence. 

Again referring to Figure 3.4, we say statement T has a loop independent 
dependence on S (denoted S^ooT) if T appears after S in the loops (i.e., T 
lexically follows S) and there exists some iteration < *r ^ Nr, (1 < 
r < n) such that each of 

fk{il, • • • , Ir, • • • , *n) — 9k{jl, • • • , Ir, • • • ,jn'), 1 k ^ 771 

holds. 

It is important that we identify the “carrier” loop of a dependence [5]. 
'I'liis is so, because many of the advanced loop restructuring optimizations 
performed later depend on this identification. VVe will define this more 
formally. 

Let wi be the number of loops containing statement S, 

: A'(/(a:i,...,3-,„)) = ... 


and n 2 be the number of loops containing statement T, 


T: A = G{X(f{xu.-.,x„,)) 


Let / and g be subscript mappings 


g:Z^^ ^ Z”* 
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where m is the miinher of subscripts for array X, Z is the set of all integers, 
G'O is an arbitrary function. denote the induction variables 

for the loops. Further, the upper bound of the loop surrounding S 
is cissumed to be A/;; the upper bound of the loop surrounding T is 
assumed to be iV,-. So if n is the number of common loops surrounding the 
two statements, M,- = Ni, forall 1 < i < n. 

We say statement T depends on statement S with respect to carrier k [5] 
{k < 7i), written S 6 k T, if there exist (I'l,. . . ), 

{lk+iJk+2, • • • 7 fiij)) and integers (i, C2 in the following regions : 

1 < t, < Nq \fq s.t. 1 < 9 and q < k 
1 < j, < Mq Vq s.t. k < q and q < ni 
1 ^ k < q and q < n2 

I < Cl <C2<Nq 

such that the following equation holds: 

y{^'l 7 • • • 7 1 7 Cl 7 jk+li • • • 7 Jni ) “ 7 ■ • • 7 *'*—17 C27 ^*+1 7 • • * 7 ) 

Depth of a dependence. We say that statement T depends on statement S 
at depth d (denoted S T)[5], if there exists & k> d such that S 6 k T. 

Nesting Level of dependence. For statements S and T,j 7°(S,T), the nesting 
level of the diixct dcpcndencc[b] of T on S, is defined as the maximum 
depth at which the dependence exists. 

For statements S and T, r;(S,T), the nesting level of the dependence [5] of 
T on S, is defined as the maximum depth d at which there exists a path 
(Po, Fi,...,Pn) such that, 

S = PoAdPiAdP 2 ^d ... ^dPn = T 

Parallelism Index ( p ). Consider a statement S that depends upon itself. 
The parallelism index of 5, piS) is defined as 

..ENTR- ■ 

p{S) = 7n - 7/(5, 5) ' 
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where m is the number of loops containing 5. The implication of the 
parallelism iiulex is that if p{S) > 0 , then S' may be executod in parallel 
in the innermost p{S) loops surrounding it. 

3.2 Dependence Testing 

A majority of array references in practice have been observed to be linear func- 
tions of the loop induction variables, which somewhat reduces the complexity of 
solving the dependence problem. Equations involving linear functions of vari- 
ables (i.e., equations of degree 1) are commonly know as linear diophantine 
equations and have the form 

aiXi + 02X2 + 03X3 + ...+ UnXn = c 

where Xi,X2,.. Xn are the variables to be solved. 

Further, the loop induction variables take on only integer values and are bound 
by some u[)per limits. This fact reduces the problem to deciding whether a 
solution exists for a given set of linear diophantine equations in a bounded 
region. In other words, the linear dependence problem always involves solving a 
system of linear diophantine equations subject to a set of linear coiistramts. 

There are two major types of dependence tests: ezacT and inexact or approx- 
imate. In an exact test, we actually find the general (integer) solution to the 
system of equations and test to see if a solution exists that fits all the con- 
straints. In an inexact test, we check if there is an integer solution to the 
system or to each individual equation, subject to the constraints. Inexact tests 
are much less expensive compared to the exact tests as they address the simpler 
question “does dependence exist?” rather than the more specific “what itera- 
tion instances cause dependence?” and can be tuned to find dependence at a 
particular level. ^ 
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3.2.1 GCD Test 

This is an inexact test whicli borrows the concept of Gi'catest Coinnion Divisor 
from the realm of Number Theory and attempts to apply the same to solve the 
dependence problem. 

Algorithm 3.1: GCD Test [7] Given a system of m linear diophantine equa- 
tions 

fr{x) = arlXl -I- ar2X2 + • - • + CmXn = (1 < T < m) 

in n variables, then, for each r, 1 < r < m, do the following: 

Step 1 : I'Miul //(•</(</, !, <ir 2 , ..., «rn) using Kuclid’s algorithm 
Step 2 : If this gcd does not divide tv, the rth equation (and hence the 
system) has no solution; terminate the algorithm 
Step 3 : Assume there is dependence 

The GCD test is quick, but is relatively ineffective in practice. The gcd of a set 
of numbers is one more often than not, which reduces the utility of this test. 

3.2.2 Extended GCD Test 

Algorithm 3.1 tests each linear diophantine equation individually. Instead, if we 
test for the existence of a solution to the system as a whole, there is some scope 
for improvement. The resulting test, called Generalized GCD test by Banerjec 
[7] borrows some concepts from Matrix Theory. We will briefly look at some 
matrix terminology. 

Unimodular matrix. A square matrix A is unimodular if 

determinant{A) = ±1 

Echelon matrix. An mxn matrix is an echelon matrix if it has the following 
form: 

1. For some k inO < k < 77i, the last k rows consist entirely of zeros 
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2. For 1 < i < m — if the first nonzero element on row * lies in column 
j, then each element in column j after row i is zero. 

3. The first nonzero elements in the rows are in an echelon form. 

Now we will give the extended GCD test. 

Algorithm 3.2: Extended GCD Test [7] Consider a system of m linear dio- 
phantine equations 

/r(x) = flriari + ar2X2 + - • • + a^Xn = Cr, (1 < T < m) 

in 7j. variables. Lot A tlenoto the n x rn eoeincient matrix [uritlS C the 
m X 1 matrix [cr]‘. Then, 

Step 1: Find U, an n x n unimodular integer matrix and D an n x m an 
echelon integer matrix such that UA = D [7]. 

Step 2: If an m x 1 integer matrix T satisfying TD = C does not exist, 
then the system has no solutions and the algorithm terminates. 

Step 3: Assume there is a solution. 

3.2.3 Banerjee’s Test 

Banerjee noticed that the Intermediate Value Theoi'em has an important bear- 
ing on the dependence problem and applied it to try and solve the same. Here, 
we produce the theorem from [7]. 

Theorem 3.1 (Intermediate Value Theorem) Let f be a continuous real 
valued function on RP'. Let 6, B denote any two values of f on a connected set 
C BP, and suppose that b < c < B. Then the equation 

f{x) = c 


has a solution a: € 3?. 


□ 
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The implication of this theorem is that, if we evaluate the upper and lower 
bounds of / and verify if c lies within these bounds, then there exists a real 
solution I in 9? that will satisfy /(x) = c. But this is still not conclusive as 
the existence of a real solution does not guarantee the existence/absence of an 
integer solution, which is what is sought. 

3.2.3. 1 Banerjee’s inequality 

Consider a system of m linear diophantine equations 

fr{x) = ttrlXi + nr2X2 + - • - + = C^, (1 < T < Tu) 

in n variables and a nonempty region 9? C Z^. If cv does not satisfy 

btowifr,^) <Cr < 6up(/r,3?) 

then there is no solution to the equation (and hence to the system). 

3. 2. 3. 2 Determining the bounds of 92 

The region 92 C /2" in which we search for the existence of an integer solution 
is defined by the iteration space. In general, the region defined will be either 
I'ectangular (loop bounds remain unchanged once execution of loop nest begins) 
or trapezoidal (loop bounds being functions of other variables). 

The examples in the Figure 3.5 and 3.6 illustrate the concept of “bounds” of 
loops. Banerjee proposed algorithms to find the bounds of 92 in both the cases. 


Notation 

If a is a real number, the positive and negative parts of a are defined as 

a'*' = max{a, 0} 
a~ = mm{— a, 0} 



ENDDO 


ENDDO 


Region 

of 

Interest 


j 


Figure 3.5: Rectangular iteration space 



Figure 3.6: Trapezoidal iteration space 
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3. 2. 3. 3 Bounds in rectangles 
Consider a linear diophantine equation, 

f{x) = aiXi + 02^2 + . • - + OnXn = C 

If 3? is a rectangle, and Pa < a:jt < for 1 < A: < n, then the minimum value is 
given by 

n 

btowifr,^) = Y^iatpk - alqk) 
k=i 

and the maximum value by 

^.;.(/r, 3 ^) = -<hPk) 

k=l 


3. 2. 3. 4 Bounds in Trapezoids 
Consider a linear diophantine equation: 

f{x) = aiXi -f 02X2 + . . . + a^Xn = c 
Let the constraints for 3? be: 


Pio ^ 3:1 < ^10 

P20 + P2i^i ^ 3:2 < 920 + 9212:1 

PnO + Pnl^l + . . . + Pn,n-l 2 :„_l < a:„ < QnO + qnl^^l + • • • + 9 n,n-ia:„_l 

Algorithm 3.3 in Figure 3.7 finds the bounds 6/ou/ Kp for / in 3J. 


Algorithm 3.3: Bounds in trapezoids 


1 • ^tovj ^ ^ 

bup *- 0 

(</l , ^2) • • ■ j ^n) ■* (®1 ) ^2j • • • j ®n) 
(Ci , 621 • • ■ 5 ^n) ^ ) ® 2 » • • ■ J ®n) 


2. for k 4— n downto 1 do 

{ 

blow * bioiij “I" dj^ Pko d/g (jkQ 

bup *— bup + ejj" qko — pko 

i{{k>l) 

{ 

(di,d 2 ,...,djt_i) *— {di + dfpki — dkqkXi 
^2 + d'lpk2 — df. qk2i • • • J 
djt-i + d'lpk,k-i - dlqk,k-i) 

(Ci, £ 2 ,- • • ♦— (Ci + dk^ikl ~~ HPkli 

^2 + dk qk2 ~ ^k Pkii •••■> 

&k-\ + dk^Kk-l — &kPk,k-\) 

} 

} 


3. Slop 


Figure 3.7: Algorithm for finding bounds in trapezoids 
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3.2.4 Conclusions 

After giving a fairly formal treatment to the problem of data dependence anal- 
ysis, wc will try to draw some conclusions about the tests themselves: 

• The CCD test does not restrict the existence of a solution to any specific 
region, and searches in the entire integer space. 

• Banerjcc’s test takes the region of interest (iteration space) into account 
but fails to distinguish the cases when a real solution exists in the region 
but an integer solution does not exist 

• Both the tests are conclusive when they indicate that there is no solution 
and both of them never conclusively indicate that a solution exists; they 
only indicate that a solution tnay exist. 

Taking these factors into account, a lot of research work is going on in this area. 

3.2.5 Implementation Notes 

As of now, only GCD and Banerjee’s tests have been incorporated into the 
F9U compiler. 'J'he de{)endences between statements, if found to be existent, 
are recorded as data dependence edges in the Program Dependence Graph. 
Along with the type of dependence, the depth of the dependence and the array 
references causing the dependences are also stored in the edge structure. 


Chapter 4 

Code Restructuring 


Program Restructuring encompasses all transformations affected on the pro- 
gram, with tlu* objective of making it suitable for “faster” execution on a par- 
ticular machine architecture. These transformations include loop interchange, 
node splitting, loop spreading, loop fusion, statement reordering, strip mining, 
cycle shrinking [23] and vector/parallel code generation. The scope of these 
transformations may include changing the code or the order of the code exe- 
cuted. However, the dependences in the original code are preserved. Therefore, 
if there are two executions of statements that reference a common memory lo- 
cation before restructuring, there will be two executions that reference the same 
location after the transformation. In this chapter, we will be looking at some 
of those restructuring techniques. 

4.1 Loop Interchange 

By now, the reader will have grasped the fact that programs written in a se- 
quential language for a scalar machine are often not well suited to fully utilize 
vector hardware. Consider, for instance, Fortran code to compute the product 
of two matrices A and B [5]. The product mati-ix C is assumed to be initializcxi 
to zero. 
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DO J = 1, N 

DO I = 1, N 

DO K = 1, N 

5i: C( I,J) = C(I, J) + A(I, K)*B(K, J) 

ENDDO 
ENDDO 
ENDDO 


On a scalar machine, this code can make optimal use of registers. The outer 
two loops select an element of the product matrix C; the innermost loop then 
performs all computations involving that element. Accessing memory repeat- 
edly can be avoided by accumulating the intermediate values of C in a register. 
Thus, a good optimizing compiler can generate excellent code for this segnient. 

If we con.sid<?r converting this code segment to vector code however, we face 
problems. There is a self dependence involving carried by the K loop which 
is at level 3 in the loop nest [true dependence at depth 3). The parallelism 
index of 5’i is zero and hence it cannot be vectorized. 

Now, if we interchange the loops so that the K loop occupies the outermost 
position, 

DO K = 1, N 

DO J = 1, N 

DO 1 = 1,N 

C( I, J ) = C( I, J ) + A( I, K ) * B( K, J ) 

ENDDO 

ENDDO 


ENDDO 
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the iimennost loops can be trivially vectorized. Note that interchanging loops 
in thi.s ca.se <it>es not cijange tlie soniantics of the program. The corre.spon<iing 
program u.siiig Fortran 90 vector operations would then be 

DO K = 1, N 

C(1:N:1,1:N:1) = C(1:N:1,1:N:1) + 

A( 1 : N : 1, K ) * B( K, 1 : N : 1) 

END DO 


It is easy to see that this transformation permits better utilization of the vector 
hardware. However, effectively employing loop interchange is not a straight- 
forward matter; it requires a study of the data dependences in the program. 
This section details the concepts relating to identifying interchange preventing 
dejxmdences and performing profitable loop interchanges. 

4.1.1 Interchange Prevention 

Loop int<‘rchange fails under the category Reordering Transfoi'inations [4] of 
general code restructuring. These reordering transformations have the impor- 
tant characteristic that they do not change the code that is executed; rather 
they only affect the order in which the code is executed. More specifically, loop 
interchange only alters the order in which the loops in a loop nest are executed 
and does not change the code in the loop nest. 

Loop interchange can be applied on a pair of loops L and L' only under the 
following conditions [25]: 

1. Loops L and U must be tightly nested; i.e., L surrounds L', but contains 
no other executable statements. 

2. Loop limits of L' are invariant in L. 
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.J. Nt) intrtTbmigv piTi'enting dcpendeiices exist among the statements con- 
taiiu'd i!i L aiui //. 

we see what <iependences are interchange preventing, we make some 
important observations. The corresponding theorems and proofs can be found 
in (.1]. 

Observation 4.1 If Si has a loop independent dependence upon Si, it will be 
ptrsrrvfd by loop interchange. □ 

Observation 4.2 Any loop interchange which does not alter loops 1 through k 
ptrserves any level k dependence. □ 

4. 1.1.1 Interchange Preventing Dependences 

A tlependence that will be reversed by loop interchange is interchange pi-event- 
ing [15]. H(*cause loop interchange corresponds to a very obvious mapping on 
ilireetion vectors, interchange preventing dependences are very easy to detect 
when r<*[)res<>nted by direction vectors. A dependence prevents the interchange 
of two loops if the leftmost non “=” entry in its direction vector is “<” before 
interchange and “>” after interchange. 

Figure 4.1(4, 5], illustrates the type of dependences that can prevent loop in- 
terchange. It depicts the possible dependences of statement S on itself during 
execution of the following loops: 

DO I = 1, Ni 

DO J = 1, A^2 
S 

ENDDO 


ENDDO 
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Increasing j 



♦ 

Increasing i 



Figure 4.1: Dependence patterns in loops 


Each node in the array represents one execution of statement S. is the 
execution of S wIh'h botfj I and J are 1; Su is the execution of S when I is.l 
and J is 2 aiui so on. 

Consider the statements on which S 22 depends. If the loops are interclianged 
(corresponding to a transposition of the matrix) , the dependences of S 22 on 
5 ’ii,6'i 2 and S 21 will not be reversed, because S 22 will still be executed after 
these statements in the transformed code. However, the dependence of ^22 on 
5 i 3 will be reversed because 5'22 will be executed before S 13 in the interchanged 
code. 

The reader should note that interchange preventing dependences only inhibit 
the interchange of certain loops. For example, a dependence described by the 
direction vector {<,>,<) prevents interchange of loops 1 and 2 but not loops 
1 and 3 or loops 2 and 3. Further, Observation 4-^ absolves us from worrying 
about loop independent dependences as they can never prevent the interchange 
of any loops. 

Trivial extension of Figure 4.1 to the case of a DO loop body consisting of 
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^ Increasing j 

preserved by interchange 



Increasing i 

Figure 4.2: Dependence patterns among a sequence of statements 

more than one statement helps in the generalization of the concept. Figure 4.2 
depicts dependence patterns for the loop body: 

DO I = 1, Ni 

DO J = 1, N 2 

51 

52 

53 

Sm 

ENDDO 


ENDDO 
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In tlie above example, we have considered the two loops which are candidates for 
interchange. In Figure 4.2, the loop body S consists of a sequence of statements 
5 'i, 5 ' 2 , 53 , ...,i9m. The superscript on each oval node indicates the values of 
I and J during that execution. It is easy to see from Figure 4.2 that certain 
loop carried dependences from one statement to any other statement (including 
itself) in the loop body may inhibit loop interchange. 

4. 1.1.2 Testing for Interchange Prevention 

(15, 4 ] use the notation 7 * to denote a dependence between statements Si and 
62 whicli prevents the interchange of loops p and k. There are two approaches to 
find out if 5 ’i 7 p 52 . The first approach is the extension of Banerjee’s inequality 
by [15] which tests for interchange preventing dependences between adjacent 
loops, stated as Theorem 4.1 below. The second and less costly method involves 
direction vectors. 

Theorem 4.1 If Si and S 2 are of the form 

51 • X (/(xi, X2, • • • ) Xnj )) = ... 

52 I • . . = • • • j )) 

and occur together in at least k+1 common loops, and f and g are linear func- 
tions of the loop induction variables, i.e., 

/(*! j * 2 ? • • • 5 *ni ) — OfQ X!/ 

i=i 


* 2 > • 


na 


tnj) — 5o "h XZ 

J=1 


then Si'yjk+iS2 only if, 
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Safe 

Unsafe | 


k 

... p 

k • • • p \ 

Type 1 

< 

* < 

< ♦ > 1 

Type 2 

< = 

:+ < ♦ = 

A 

+ 

VI 

11 

Type 3 

< 

<+ < 

A 

II 

+ 

V 

* 

11 


Table 4.1: Safe and Unsafe loop interchanges 


<■*+1 -bk- E(“.' - bi)-iNi - 1) - {a; + bty(N, - 2) 

»=1 

ni 712 

E <TW-1)- E W -1) 

712 Til 

<E*i-E“.'^ 

1=0 1=0 

<■1+1 -h + Elo. - - 1) + (4 - - 2) 

1=1 

+(ai+. + 6;+,r(/v»+, -2)+ E 4(Mi-i)+ E ‘rw-i) 

i=i:+l «=A!+1 

□ 

Theorem 4.1 in effect determines the absence of direction vectors of the form 
(= •••,<,>,*) and can be trivially extended to test for the interchange of any 
loops k and p. This is done by checking for feasibility of moving loop k all the 
way up to p by swapping adjacent loops, and then moving loop p all the way 
down to k. 

Testing for interchange prevention gets simplified when direction vectors are 
used. Table 4.1 [4] lists direction vectors that permit and prohibit interchange 
of two loops k and p. The three types of dependences depicted in the table 
represent : 

Type 1: A level k dependence which directly prevents interchange of loops k 
and p 

Type 2: A level q dependence which directly prevents interchange of loops k 
and p, where g € { /, m, . . . , o } 
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Type 3: A level k dependence which will reverse on interchange because of 
some loop 9 € { /, , o }. 

4.1.2 Profitability of interchange 

From the definition of parallelism index of a statement 5, we can derive that 
loop interchange is profitable whenever it moves a recurrence outward, thereby 
decreasing t}{S, S) and increasing the parallelism index. In terms of directions 
of dependence, a loop interchange may be profitable when an inner “<” <lc- 
pendence causing loop is swapped with an outer “=” dependence causing loop. 
However, it is possible that the same outer loop may be having direction “<” 
for another dependence. When interchange is performed, this dependence edge 
moves inwards, with the result that its nesting level increases*. So, we can say 
that an interchange is profitable when, for a majority of statements in the loop 
body, the recurrence moves outwards. 

4.1.3 Interchange effects on dependences. 

Studying the effects of interchange is as important as the study of its feasibility. 
This becomes evident as one realizes that when we change the order of execution 
of loops as during interchange, we are actually changing the relative positions 
(levels) of the loops in the loop nest. The fact that loop carried dependences 
within loops are represented as being “carried” by particular levels further en- 
dorses a thorough analysis of the effects of interchange on the dependences. The 
following theorems [4] throw light upon this topic. The reader is referred to [4] 
for the proofs of these theorems. 

Theorem 4.2 If loops k and p (k < p) are validly interchanged, then all loop 
independent dependences, all dependences with level < k, and all dependences 
with level > p are unaffected by the interchange. □ 


^Such dependences are called interchange sensitive dependences 
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Theorem 4.3 // loops k andp (k <p) are validly interchanged, then all level p 
dependences in the original code become level k dependences in the transformed 
code. □ 

Theorem 4.4 If loops k andp (k < pj are validly interchanged, then all level k 
dependences in the original code become level x dependences in the transformed 
code, where k < x < p. □ 

Theorem 4.5 In a valid loop interchange of loops k and p, a level x edge will 
either become a level k edge or remain a level x edge, where k < x < p. □ 

4.1.4 Two approaches to interchanging loops 

[4] describes a modified version of the parallel code generation algorithm (code- 
gen [15]) to incorporate loop interchange. We will, on the other hand be con- 
centrating on manipulating the PDG before the already implemented procedure 
codegen is called in order to minimize changes to it. This subsection describes 
two approaches to the task. Algorithm 4.1 is applicable to interchanging adja- 
cent loops. For interchanging non-adjacent loops, the dependences within the 
loop nest have to be augmented with the addition of direction vectors. Algo- 
rithm 4.2 in Figure 4.4 outlines the resulting interchange procedure. 

While the first approach involves nothing more than the straightforward ap- 
plication of the concepts presented so far, the main reason why it cannot be 
applied to interchanging non-adjacent loops is the cost of Theorem 4.1 in this 
case. In other words, if there are r loops between arbitrary candidates loops for 
interchange k and p {k < p),2r-\-l inequalities similar to 7 of Theorem 4.1 must 
be tested to guarantee the safety of loop interchange, r -f 1 tests correspond to 
moving the p loop out to the position of the k loop, and r tests to moving the 
k loop to the original position of p, all by adjacent interchanges. 

This bottleneck for interchange can be eliminated by using direction vectors 
to test for feasibility of interchange. Algorithm 4.2 in Figure 4.4 outlines the 



A*gorit|„„ 4.1 

Step 1. 

wring dependence analysis, 

for (each level = MaxDepth downto 1){ 

(1.1) Apply Theorem 4.1 and mark dependence 
edges to indicate whether 

they prevent interchange of loops level and level — 1 

(1.2) If (no interchange preventing dependences are found) { 
Swap the elements corresponding to level and level — 1 
being considered for interchange; 

Test for dependence; 

If (dependence has disappeared at that level) { 
add level to the list of profitable interchanges 
for the dependence under consideration; 

} 

} 

} 


Step 2. 

(each loop nest) 

for (each dependence within) 

for (each level in the list of profitable interchanges) { 

if (no interchange preventing dependences exist at that level) { 
switch the loops level and level — 1; 

/* Update dependences */ 
for (each dependence in the loop nest) 
if (depth of dependence == level) 
depth of dependence = level — 1; 

} 

} 

} 

} 


Figure 4.3: Algorithm for interchange of adjacent loops 
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resulting approach, assuming that the dependence direction vectors have been 
found during dependence analysis. 

4.2 Node Splitting 

It is fairly common to find recurrences that have an essential dependence edge 
that represents an output dependence or antidependence. Single statement 
recurrences due to these “pseudo” dependences can be safely ignored thanks to 
the fetch-before-store vector semantics of Fortran 90. Matters are not as simple 
as this when two statements are involved in a dependence cycle, where one of 
the edges is an autidepeadeuce edge. This section deals with the issues involved 
in breaking such dependence cycles. 

Node Splitting involves renaming the variable or array reference that causes 
the antidependence edge, and combined with Statement Reordering, forms a 
powerful vectorizing aid. While breaking recurrences due to true dependences 
is complicated and in many cases not possible. Node Splitting is fairly straight 
forward. The technique is best illustrated with the aid of the example shown in 
Figure 4.5(5]. F() and G() are some functions. 

The dependence graph for the example is shown next to it. As it is, it is not 
possible to vectorize the loop block in Figure 4.5 because of the dependence 
cycle. If we introduce a new variable and assign to it the variable causing 
the antidependence as in Figure 4.6 , the dependence cycle is broken. Now 
we can safely perform a topological sort on the dependence graph {statement 
reordering) to get the vectorizable code segment in Figure 4.7. General prudence 
however, dictates that one has to cautiously weigh the efficiency gained by 
this transformation against additional storage requirements for the temporary 


arrays. 
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Algorithm 4.2Jnttrchange(LoopNtst) 

/* SCCs ill LoopNest are found and stored in scc_components */ 
find_sccsJn_dependence^raph( LoopNest, scc_components ); 
distributeJoops(scc_components); 

f* Consider loops of farthest distance first and proceed towards 
interchanging adjacent loops; this automatically generates the 
best sequence for intercliange */ 
for (each scc_component[i], 1 < i < no_of_components){ 
for { k = 1] k < maxJevels; Ar + + ) { 

for ( p = maxJevels; p > k; p ) { 

/* Consider interchanging loops k and p */ 

/* The SCCs at level p in the region scc_component[i] are found. 

A^i is used to store the number of cycle less regions that result 
(statements vectorizable) */ 
find_sccs_atJeveLp (scc_component[i], Ni); 
j* Is safe interchange possible ? if no, go to next p */ 
if (direction_vector[p] == “>” in any dependence edge) 
continue; 

/* Apply rules of table 4.1 to find out the existence of 
interchange preventing dependences for loops k and p */ 
findJfJnterchangeable(A;, p) 
if {k and p are interchangeable) { 

/* The SCCs at level k in the region scc_component[i] are found. 
N 2 is used to store the number of cycle less regions that 
result (statements vectorizable) */ 
find-sccs-atJevelJc (scc_component[i], A^ 2 ); 
if {Ni < N 2 ) { 

swapJoops(fc, p); 

/* Use direction vectors to identify new “carriers” 
of dependences within scc-component */ 
update_dependences(scc_component [i]) ; 

/* go to next k */ 
break; 

} 

} 

} 

} 

} 


Figure 4.4: Algorithm for general loop interchange 
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DO I = 1, N 

5i:A(I) = G(X(I + l) + X(I)) 
52: X ( I + 1 ) = F ( B ( I ) ) 

ENDDO 



Figure 4.5: Sample program for Node Splitting 


DOI = 1,N 

S': TEMP ( I ) = X ( I + 1 ) 

5i:A(I) = G(TEMP(I) + X(I)) 
52: X ( I + 1 ) = F ( B ( I ) ) 

ENDDO 



Figure 4.6: Node 5i has been split 


4. 2.0.1 Implementation Notes 


During data dependence analysis, array references causing dependences are 
stored in each edge structure. This facilitates quick identification of the ar- 
ray reference causing the anti dependence edge and replacing it by the new 
variable. 


4.3 Vector Code Generation 

The vector code generation algorithm used in the F90 compiler, in principle 
works on the same lines as the one in [5]. 

Coarsely, the code generation technique consists of the following steps. 

Step 1: Find all the strongly connected regions in the program dependence 
graph consisting of both the control dependence and data dependence edges 
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DO I = 1, N 

S': TEMP ( I ) = X ( I + 1 ) 

X ( I + 1 ) = F ( B ( I ) ) 

5,: A ( I ) = G ( TEMP ( I ) + X ( I ) ) 

ENDDO 

Figure 4.7: Node Splitting followed by Reordering 

Step 2: Reduce the dependence graph to an acyclic graph by treating each 
strongly connected region as a single node, or 7r-block 

Step 3; Generate code for each 7r-block in an order consistent with the depen- 
dences. Topological sort is performed, to first generate code for blocks that 
depend on no others, then for blocks that depend only on blocks for which 
already code has been generated, etc. 

The codegen procedure of [5] operates on the data dependence graph and vec- 
torizes statements not contained in any strongly connected component of data 
dependences. To handle conditional statements, IF-converswn[3] is first per- 
formed converting control dependences to data dependences. However, the PDG 
provides a unified way of representing both the control and data dependences 
and allows treating both the types of edges uniformly. Any node in the PDG not 
contained in a strongly connected component consisting of both the control and 
data dependences can be vectorized. Thus, the essential difference lies in the 
way the x-blocks are found. The procedure vectcodegen given as Algorithm 4.3 
in Figure 4.8 captures the essence of vectorization, as used in the F90 vectorizer. 



4.4 Vectorizing Conditionals 

Vector languages such as Fortran 90 include features that allow conditional as- 
signments to take place simultaneously on an array. Also called masked array 
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Algorithm 4.3;vectcodcge!j(Rcgion, Pdg, MinNestLevel) 

f* Region is tiie region for whicli vector code must be generated */ 

/* Pdg is the Program dependence graph of the statements in Region */ 
/* MinNestLevel is the minimum nesting level of possible parallel loops */ 
3r .blocks = FindSCCsInPDG { Region, Pdg ); 
for { each s’.blockfi], 1 < i < NoOJComponents ){ 
if ( 7r_block(i] is strongly connected ){ 

generate a level MinNestLevel DO statement; 

Regiorii = PDG considering all edges in Pdg internal 
to r_block[i] with level MinNestLevel+1 or greater; 
vectcodegen( 7r_block[i], MinNestLevel+l, Regiorii ); 
generate level MinNestLevel ENDDO; 

else 

NoEncIosing Loops = FindNoOfEnclosingLoops ( 7r_block[i] ); 
generate vector statements for 7r_block[i] in 
NoEncIosing Loops - M inN estLevel + 1 dimensions; 

} 

} 


Figure 4.8; Algorithm for Vector code generation 

assignments, these are used to mask the evaluation of expressions and assign- 
ment of values in array assignment statements, according to the value of a 
logical expression. Fortran 90 provides this facility in the form of WHERE con- 
struct or WHERE statement. The syntax of WHERE statement and construct 
is produced here for reference [11]. 
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where-stmt 

whet'e-construct 


where-conatruct-stmt 

mask-expr 

elsewhei'e-stmt 

end-whei'e-stmt 


IS WHERE ( mask-expr ) assignment-stmt 
IS where-consiruct-stmt 
[assignment-stmt] 
elsewhere-statement 
[a5si^nmenf-sfm<]. . .] 
end-where-stmt 
IS WHERE ( mask-expr ) 

IS logical-expr 
IS ELSEWHERE 
IS END WHERE 


The following subsection discusses the issues involved in converting IF state- 
ments to WHERE form. 

4. 4. 0.2 Issues 

When we talk about IF statements, we are talking about conditional execution 
and hence are firmly in the domain of control dependences. Before the program 
dependence graph was proposed, a process called “IF-conversion” [3] was used 
to convert control dependences to data dependences. 

IF-conversion is accomplished by converting all statements under the control of 
an IF or branch to conditional statements. These conditional statements are 
then translated to vector statements viewing the conditional expression as just 
another “read” in (input to) the statement. 

However, IF-conversion is non- trivial and hopelessly fragments the control struc- 
ture of a program. For instance, the DO loop nest 
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DO 1 = 1, 100 

IF { A(I) > 100 ) goto 60 
5,: A(I) = A(I)*5 

IF ( B(I) > 100 ) goto 80 
S 2 : B(I) = B(I) - 100 

53 : 60 A(I) = A(I) - B(I) 

S 4 : 80 B(I) = A(I) + 5 

ENDDO 


upon IF-conversion translates to, 

DO I = 1, 100 

BRl = A(I) > 100 

Si: IF ( .NOT. BRl ) A(I) = A(I) ♦ 5 

IF ( .NOT. BRl ) BR2 = B(I) > 100 
52 : IF ( .NOT. BRl .AND. .NOT. BR2 ) B(I) = B(I) - 100 

S 3 : IF ( BRl .OR. .NOT. BR2 ) A(I) = A(I) - B(I) 

54 : B(I) = A(I) + 5 

ENDDO 


This can be converted (fortunately!) to a sequence of WHERE statements. 
Quite often, IF statements can be part of recurrences, in which case vector- 
ization is not possible. It is under such conditions that recovering the original 
control flow of the program from the IF-converted one becomes necessary. 

In the cases where the PDG is used to represent the program, as in our case, 
there is no such fragmentation of the control flow. As the PDG allows uniform 
handling of control and data dependences, while finding the strongly connected 
components, we consider both the control and data dependence edges and handle 
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IF statements just like the ordinary assignment statements, 

4.4.0.3 Loop Exit IPs 

The class of IF statements within DO loops that conditionally branch out of 
the loop, are called loop exit IFs. There is no general procedure to vectorize 
loop exit IFs and some heuristics may be applied [ 25 ], There are several issues 
to be considered: 

• The resulting vectorized code may take longer to execute than the original 
serial code. For example, 

DO I = 1 , N 

A(I) = B(I) + C(I) 

IF ( A(I) > REF(I) ) goto label 
ENDDO 
label: , . , 


If simplistically vectorized, the above segment results in 
Si: A( 1 :N) = B( 1 :N) + C( 1 :N) 

S2: FLAG( 1 :N) = A( 1 :N) > REF( 1 :N) 

53: I = FIRST.ONE ( FLAG( 1 :N) ) 

54: IF ( I > 0 ) goto label 
label: . , . 


FIRST-ONE is a function that returns the index value of the first array 
element set to 1 , If N is large, and the loop exit condition is satisfied for 
some small I, then the serial version will execute only I iterations while the 
vectorized version will execute all iterations of Si and S2 before finding 
that the last N— I iterations were indeed, unnecessary. 
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• Observe that, in the above segment, all the values of A in Si are changed 
so tliat the vectorized code, when executed may produce incorrect results. 
This can be circumvented by assigning all results computed in the loop 
to some compiler temporary arrays. Proper results can be copied to the 
program variables after the loop exit condition is found. 

• It is difScult to predict the effect of executing the vectorized code. For 
instance, suppose that for some computation of Si a run time error (say 
overflow) is bound to occur. Also suppose that this instance of is not 
executed in the sequential version; all goes well. In the vector version 
however, as all instances of are executed, there will be a fault. 

In general, it is extremely difficult to vectorize loop exit IFs as most of these 
loop conditions are determined at run time. Predicting their run time behavior 
at compile time is impossible with the existing compiler techniques. 


Chapter 5 
Epilogue 


5.1 Summary 

The vectorizer is capable of optimizing most of the practically occurring code 
patterns. In this thesis, we have concentrated on describing concepts related 
to loop optimizations for maximal extraction of concurrency in code segments. 
While all the other phases of the compiler use the syntax tree as intermediate 
representation, the vectorizer uses the Program Dependence Graph as the in- 
ternal representation. The increase in time taken by the compiler because of 
the conversion from the syntax tree to the PDG is offset by the convenience 
of handling control and data dependences uniformly. Array dependence anal- 
ysis forms the backbone of vectorization. Going deeper with array subscript 
analysis rather than the cursory examination based on array names goes a long 
way in uncovering the (possible) absence of dependences. Loop interchange is 
performed on a loop nest only if it results in increasing the parallelism index of 
the majority of the statements within the loop nest. So, if loop interchange docs 
take place, it invariably results in producing a more vectorized code than was 
possible before. While Node Splitting breaks dependence cycles with antide- 
pendences as components, the vector code generation routine recursively tries 
to break true dependence cycles at greater depths. The presence of a vector 
facility for conditional assignment as an added bonus is tapped to convert IF 
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constructs that do not branch out of loops to equivalent WHERE constructs. 
Finally, we have discussed issues relating to vectorizing the loop-exit IFs. 

5.2 Status of Implementation 

Currently, the F90 vectorizer is capable of performing the following loop opti- 
mizations: 

• loop normalization, 

• auxiliary induction variable elimination, 

• interchange of adjacent loops, 

• node splitting, and 

• generation of vector code for array assignments and IF constructs that do 
not branch out of the loop. 

The dependence analysis phase uses GCD and Banerjee’s tests to determine 
dependences between array references. 

5.3 Testing of the software 

The vectorizer is an optional feature of the compiler that can be invoked by 
specifying the “-V” option on the command line. Examples were designed to 
test each phase of the vectorizer. More specifically, examples to test various 
scenarios in the following were conceived and used: 

• Performing loop normalization 

• Identification and elimination of auxiliary induction variables 

• Performing array dependence analysis 

• Performing feasible and profitable loop interchanges 

• Performing node splitting 
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• Vectorizing conditionals, and finally, 

• Generating vector code 

The vectorizer, being a part of the larger compiler project consisting of phases 
like the front-end and the scalar optimizer coming before, and the unparser 
coming after, has to work hand-in-hand with them. So test caaes were crafted to 
validate the integration of the vectorizer with the compiler. About 40 programs 
of size ranging from 5 lines to 35 lines of code were used to test the vectorizer. 

5.4 Future Directions 

Even though the F90 compiler extracts parallelism to generate the vectorized 
code in most of the practical cases, there is scope for improvement. In particular, 
future work may concentrate on the following areas: 

• Augmenting the dependence testing by the addition of more dependence 
tests. While the GCD test proves ineffective in most of the practical cases, 
Banerjee’s test requires the bounds of the region to be known. Both of these 
tests are inexact tests and incorporating some more tests like the I-test[17], 
Power test[26], Delta test[14], etc., will help in somewhat neutralizing the 
inaccuracies due to GCD and Banerjee’s tests. 

• Handling input instructions. As of now, the vectorizer cannot identify 
dependences resulting from the presence of such statements in loop bodies. 

• Another direction in which the dependence testing phase may be extended 
is in handling procedures and functions. This will require analysis to be 
done at the local and the global levels to identify dependences between 
references under the same scope. 

• The vectorizer as of now handles only adjacent loop interchanges. The 
reason for this decision was the expense involved in computing the feasi- 
bility and profitability of general loop interchange. However, if need be. 
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this phase can be extended to perform general loop interchanging using 
the algorithm suggested in this thesis. 

• Presence of loop exit IFs in DO loops severely hampers vectorization. This 
is so because in most of the cases, the conditions under which the loop is 
exit become evident only during execution. However, in some specific 
cases, these IFs are less unpredictable ajid can possibly be vectorized. A 
study can be done to enumerate conditions under which such vectorization 
can be carried out, and with the application of some ad-hoc techniques, 
concurrency can be tapped. 

• Extensions to the project can also concentrate on determining the possible 
existence of program segments equivalent to REPEAT-UNTIL loops: 

label: 


IF ( condition ) goto label; 


and WHILE-DO loops: 

label 1: IF ( condition ) goto label2; 

goto labell; 


Iabel2: 
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